<html>
<head><meta charset="utf-8"><title>Extending indexing to more types · t-lang · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/index.html">t-lang</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html">Extending indexing to more types</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="195472403"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195472403" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195472403">(Apr 27 2020 at 20:41)</a>:</h4>
<p>AFAIK there's appetite to do this, so I wanted to start a conversation to try to find a way.</p>
<p>Here's a stab at requirements:</p>
<ul>
<li><code>a[1]</code> continues to compile (it doesn't give an inference failure)</li>
<li>off-by-one errors continue to fail (whether panic or <code>None</code>), not to silently return the other end</li>
<li>not edition-tied, because we would want things like <code>impl Index for Vec</code> to be updates as well, which cannot be edition-tied</li>
<li>supports <code>.get()</code> and friends, not just <code>[]</code>, with the usual panic implications (so <code>.get()</code> shouldn't ever panic, even if the index is "way too big")</li>
</ul>
<p>Non-goals:</p>
<ul>
<li>supporting python-style <code>a[-1]</code>, as it contradicts a requirement above (Should we want to do this we could do it with an opt-in of some sort, strawmen <code>a[Wrapping(-1)]</code> or <code>a[Reverse(0)]</code> or <code>a[^0]</code> -- <a href="https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#indices-and-ranges" title="https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#indices-and-ranges">taken from C#</a> -- or <code>a[$-1]</code> -- <a href="https://dlang.org/articles/d-array-article.html#introducing-slices" title="https://dlang.org/articles/d-array-article.html#introducing-slices">taken from D</a>.)</li>
<li>customizing index types for arrays or slices, such as requiring <code>u8</code> to index into a <code>[i16; 256]</code>.  (I think this would necessarily be a breaking change, and can be handled acceptably with newtypes.)</li>
</ul>
<p>Precedents:</p>
<ul>
<li>Bitwise shift operations support any type, even though they never need a value above 128.  (<code>1 &lt;&lt; u128::MAX</code> and <code>1 &lt;&lt; i128::MIN</code> are legal rust code, though we do warn about them.)</li>
<li><code>usize</code> is already bigger than necessary for _every_ slice (that doesn't contain ZSTs).  And much, much larger than needed by the vast majority of arrays and slices. (<code>[1][usize::MAX]</code> is legal rust code, though we do warn about it.)</li>
</ul>
<p>Known issues:</p>
<ul>
<li>Just enabling the unsigned types for indexing gives inference failures on literals<ul>
<li>Easiest fix: allow indexing by signed types too.</li>
<li>Possible fix: some kind of different inference fallback, or defaulting.  This is historically hard; might it be any easier when it's just for <code>{integer}</code>?</li>
</ul>
</li>
</ul>



<a name="195474085"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195474085" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195474085">(Apr 27 2020 at 20:57)</a>:</h4>
<p>I don't really think a different inference fallback is very viable</p>



<a name="195474119"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195474119" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195474119">(Apr 27 2020 at 20:57)</a>:</h4>
<p>Or at least the barrier to arguing for that solution  seems pretty high to me</p>



<a name="195474151"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195474151" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195474151">(Apr 27 2020 at 20:57)</a>:</h4>
<p>Especially because I feel like <code>i32</code> indicates aren't totally impossible to imagine anyway</p>



<a name="195474175"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195474175" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195474175">(Apr 27 2020 at 20:57)</a>:</h4>
<p>you can imagine some computation that yields a valid index but where intermediate values may become negative easily enough</p>



<a name="195479850"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195479850" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195479850">(Apr 27 2020 at 21:51)</a>:</h4>
<p>Yeah, I prefer the "just allow signed" solution.  Because, to me, <code>a[i-1]</code> wrapping to <code>usize::MAX</code> is actually worse than <code>a[i-1]</code> giving a panic message mentioning <code>-1</code>.</p>



<a name="195479957"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195479957" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195479957">(Apr 27 2020 at 21:52)</a>:</h4>
<p>(Which is also what contributes to me putting the "off-by-one needs to fail" requirement in the OP.)</p>



<a name="195480027"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195480027" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195480027">(Apr 27 2020 at 21:53)</a>:</h4>
<p>I'd like to throw in a requirement that the inference (or whatever) doesn't interact poorly with the desire for implicit promotion (e.g. <code>u8 -&gt; usize</code>), even if I think it's not 100% that we want that yet</p>



<a name="195480654"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195480654" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195480654">(Apr 27 2020 at 22:00)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116009">nikomatsakis</span> <a href="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195474151" title="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195474151">said</a>:</p>
<blockquote>
<p>Especially because I feel like <code>i32</code> indicates aren't totally impossible to imagine anyway</p>
</blockquote>
<p>How incredibly disruptive would it be to question the default <code>i32</code> inference for integers?</p>



<a name="195480712"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195480712" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195480712">(Apr 27 2020 at 22:01)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116009">nikomatsakis</span> <a href="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195474085" title="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195474085">said</a>:</p>
<blockquote>
<p>I don't really think a different inference fallback is very viable</p>
</blockquote>
<p>Even just "default to <code>usize</code> if used in indexing and no other constraints"?</p>



<a name="195480834"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195480834" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195480834">(Apr 27 2020 at 22:02)</a>:</h4>
<p><span class="user-mention" data-user-id="116122">@simulacrum</span>  Hmm, if we support _every_ integral type then there'd never be implicit promotion opportunities, right?  (I'm also not sure what kind of promotion you're thinking about.  Maybe start another topic about it?  Personally the last it came up on IRLO I ended up convinced that we should never do even implicit widening.)</p>



<a name="195480877"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195480877" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195480877">(Apr 27 2020 at 22:03)</a>:</h4>
<p><span class="user-mention" data-user-id="239881">@Josh Triplett</span> I think that it would need to work for things like <code>.get(1)</code> as well -- not just <code>[1]</code> -- for consistency, which might make it harder to focus.</p>



<a name="195480879"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195480879" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195480879">(Apr 27 2020 at 22:03)</a>:</h4>
<p><span class="user-mention" data-user-id="125270">@scottmcm</span> Yeah, implicit widening is not something I'd want to see. That's separate from "let's make operations smarter".</p>



<a name="195480965"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195480965" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195480965">(Apr 27 2020 at 22:04)</a>:</h4>
<p>Right; I also want to allow comparison operators between all pairs of integral types.</p>



<a name="195481028"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195481028" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195481028">(Apr 27 2020 at 22:05)</a>:</h4>
<p>I will freely admit being a little uncomfortable with that, especially between signed and unsigned types.</p>



<a name="195481034"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195481034" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195481034">(Apr 27 2020 at 22:05)</a>:</h4>
<p>I do appreciate that Rust could do the right thing, numerically.</p>



<a name="195481042"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195481042" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195481042">(Apr 27 2020 at 22:05)</a>:</h4>
<p>But "numerically" is <em>not</em> always the right thing.</p>



<a name="195481139"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195481139" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195481139">(Apr 27 2020 at 22:06)</a>:</h4>
<p>I appreciate that Rust helps me not mix integer types without thought, and I'm currently writing code that would be much harder to write if Rust didn't help me in that way.</p>



<a name="195481303"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195481303" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195481303">(Apr 27 2020 at 22:08)</a>:</h4>
<p>(Perhaps we should split this into a separate topic about comparison operators, to avoid derailing indexing?)</p>



<a name="195482785"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195482785" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195482785">(Apr 27 2020 at 22:26)</a>:</h4>
<p>So, I just dug into the status of default type parameter fallback. That led me to <a href="https://github.com/rust-lang/rust/issues/27336" title="https://github.com/rust-lang/rust/issues/27336">https://github.com/rust-lang/rust/issues/27336</a> , which led to <a href="https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496/1" title="https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496/1">https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496/1</a> .</p>



<a name="195482870"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195482870" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195482870">(Apr 27 2020 at 22:27)</a>:</h4>
<p>It looks like that got stalled on, effectively, the case of integer default versus user default.</p>



<a name="195482936"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195482936" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195482936">(Apr 27 2020 at 22:28)</a>:</h4>
<p>If we made a call on that (e.g. "always use the user default if there is one, error if that conflicts with the integer default"), would that be enough to unblock that, which would then unblock indexing, comparison operators, and so on?</p>



<a name="195483063"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195483063" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195483063">(Apr 27 2020 at 22:30)</a>:</h4>
<p>That would be enough to say, for instance, that an operator between T and <code>u64</code> should default to <code>u64</code>, but would allow another type.</p>



<a name="195483271"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195483271" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195483271">(Apr 27 2020 at 22:33)</a>:</h4>
<p>That would also make it easier to make API improvements (e.g. switching from a concrete type to a generic type defaulting to that same concrete type) without breaking API compatibility, which seems like an overall win for the ecosystem.</p>



<a name="195496165"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195496165" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Sebastian Malton <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195496165">(Apr 28 2020 at 02:28)</a>:</h4>
<p>It would be very nice if indexing be customizable for new types (like making a cyclic-vec that indexes with <code>WrappingIndex</code>). I could see something like this happening, but it would require the indexing trait to know about the "size" of the container.</p>



<a name="195594791"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195594791" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195594791">(Apr 28 2020 at 17:02)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195480654" title="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195480654">said</a>:</p>
<blockquote>
<p>How incredibly disruptive would it be to question the default <code>i32</code> inference for integers?</p>
</blockquote>
<p>Past experiences shows that the fallback is "limited" in real code but <em>very</em> common in test code. Probably "limited" by now means effectively "everywhere" anyway. (We actually did the work to remove fallback entirely at one point, and then added it back because of the impact on test code.)</p>



<a name="195595143"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195595143" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195595143">(Apr 28 2020 at 17:04)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195482870" title="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195482870">said</a>:</p>
<blockquote>
<p>It looks like that got stalled on, effectively, the case of integer default versus user default.</p>
</blockquote>
<p>I think that's not the only case where you can have conflicting defaults. Consider:</p>
<div class="codehilite"><pre><span></span><code><span class="k">fn</span> <span class="nf">foo</span><span class="o">&lt;</span><span class="n">A</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="kt">u32</span><span class="p">,</span><span class="w"> </span><span class="n">B</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="kt">i32</span><span class="o">&gt;</span><span class="p">(</span><span class="n">x</span>: <span class="nb">Option</span><span class="o">&lt;</span><span class="n">A</span><span class="o">&gt;</span><span class="p">,</span><span class="w"> </span><span class="n">y</span>: <span class="nb">Option</span><span class="o">&lt;</span><span class="n">B</span><span class="o">&gt;</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="p">}</span><span class="w"></span>

<span class="k">fn</span> <span class="nf">main</span><span class="p">()</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">  </span><span class="kd">let</span><span class="w"> </span><span class="n">z</span>: <span class="nb">Option</span><span class="o">&lt;</span><span class="n">_</span><span class="o">&gt;</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nb">None</span><span class="p">;</span><span class="w"></span>
<span class="w">  </span><span class="n">foo</span><span class="p">(</span><span class="n">z</span><span class="p">,</span><span class="w"> </span><span class="n">z</span><span class="p">);</span><span class="w"> </span><span class="c1">// now both the fallback for A and B apply to `z`</span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="195610078"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195610078" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195610078">(Apr 28 2020 at 18:54)</a>:</h4>
<p>I feel like it'd be reasonable to just error out in that case.</p>



<a name="195610152"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195610152" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195610152">(Apr 28 2020 at 18:55)</a>:</h4>
<p>Conflict between type parameter default and integer default: type parameter default wins.<br>
Conflict between multiple type parameter defaults that aren't the same type: error.</p>



<a name="195611254"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195611254" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195611254">(Apr 28 2020 at 19:05)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195610078" title="#narrow/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types/near/195610078">said</a>:</p>
<blockquote>
<p>I feel like it'd be reasonable to just error out in that case.</p>
</blockquote>
<p>one downside is that it means that adding defaults is not backwards compatible</p>



<a name="195611271"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195611271" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195611271">(Apr 28 2020 at 19:05)</a>:</h4>
<p>because it may conflict with some other user-provided default</p>



<a name="195611296"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195611296" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195611296">(Apr 28 2020 at 19:05)</a>:</h4>
<p>this is what led to the interest in a "minimal" set of defaults that cannot cause conflicts by construction</p>



<a name="195613985"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195613985" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195613985">(Apr 28 2020 at 19:28)</a>:</h4>
<p>Good point.</p>



<a name="195615009"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195615009" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195615009">(Apr 28 2020 at 19:37)</a>:</h4>
<p>in particular, the <em>main motivator</em> for these defaults (or one of them) is to enable people to migrate from a specific type to a more general type parameter, and it's "not completely met" by this design, since it may still cause conflicts</p>



<a name="195637758"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Extending%20indexing%20to%20more%20types/near/195637758" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Extending.20indexing.20to.20more.20types.html#195637758">(Apr 28 2020 at 22:42)</a>:</h4>
<p>+1 to not really needing defaults in "real code", but them being essential for peripheral code like <code>println!("{}", 1);</code> in demos and such</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>